Amiga Plus 2000 #4/Amiga Plus CD - 2000 - No. 4.iso/Tools/Emulatoren/UAE0.6.4/docs/README

Text File | 2000-05-27 | 32KB | 681 lines

This is version 0.6.4 of UAE, the Un*x Amiga Emulator.

#include <drivel.h>

Copyright 1995, 1996 Bernd Schmidt & contributors (see below). This program is
freeware. You may do whatever you want with it for personal use.
Permission is granted to redistribute this program free of charge, provided it
is distributed in the full archive with unmodified contents and no profit
beyond the price of the media on which it is distributed is made. Exception to
the last rule: It may be included on freeware/shareware collections on CD-ROM.
There are no warranties of any kind for this program. If you use this program,
you do so at your own risk. The authors are not responsible for any damages
that might result from using this program.


Overview
========

UAE emulates the hardware of an A500 with 2MB chip and a variable amount of
fast memory. Up to 11.8MB RAM are supported. It works with all Kickstart ROM
versions, provided they are not compiled for the 68020. It supports some (one,
to be precise) ECS features apart from nearly all the functionality of an OCS
chipset.

UAE was developed for Unixoid systems. Meanwhile, it has been ported to the
Mac, DOS, the BeBox, NextStep, the XFree86/OS2 environment and AA Amigas (it
can't quite run itself yet). The Mac and DOS versions are distributed with
binaries and a seperate README file that you should read after you have
finished this document. The other versions must be compiled from the source
code.

What UAE does not (yet) emulate is software. To use UAE, you need a Kickstart
ROM image as well as any other software you want to run, e.g. a Workbench
disk. Both are copyrighted, and I can't include them. Don't ask me to send
them to you.
Since the PC floppy controller can't read Amiga disks (yes, that's a fact),
floppy access has to be emulated differently: Floppies are emulated by means
of disk files that contain a raw image of the floppy disk you want to emulate.
Read the section "tools" below for information how to create ROM images and
disk files.
You can also emulate a harddisk. UAE can mount native filesystems as
harddrives, so once you have booted it up, you can access all your files on
the harddisk. It is currently impossible to boot from the emulated harddisk.
I don't have a clue why.

I am developing UAE using Linux. Only if you are running Linux can you be
reasonably sure that all versions of UAE will work for you. On other Unix
systems, you may encounter problems from time to time. I can make no
guarantees about the NextStep and BeBox versions, these are very recent ports
and will probably need some more time before they compile/run reliably.

These are the requirements for getting the Unix version to run:
  - X11, or SVGAlib if you are using Linux.
  - an ANSI C compiler. GCC is _strongly_ recommended.
  - Optionally, tcl7.4/tk4.0

Note: some Linux installations (usually Slackware) are broken. If you get
linker errors ("final link failed: bad value"), you need to upgrade the
binutils package that you can find on sunsite.unc.edu:/pub/Linux/GCC
Before installing anything from that directory, read the corresponding
release.* files.
You'll get better performance if you are using an ELF system.

On Linux, 8MB are sufficient to run UAE, although startup will be much faster
if you have some additional memory. The DOS version also works with 8MB, but
startup is slow there too. I have not tried the other ports, it may well be
that other OS's are better at wasting memory. At least 16MB are recommended.

This section is just what it says: an overview. Please read _all_ of this
file, especially if you have problems. Please read also the file "FAQ" which
contains some Frequently Asked Questions (and even the answers!)


Installation
============

To build UAE, first unpack it to an appropriate directory (e.g. /usr/src/uae
on a Linux system). After that, you will have to edit the file config.h to set
some configuration options. Then, you should give the command "configure".
This script will determine what type of system you are using. It will then
create an appropriate Makefile. Type "make" after that to build UAE.

If you are running Linux, you can say "configure --without-x" as an
alternative. If you do this, UAE will be configured to use the SVGA library.
If you use SVGAlib, be warned that SVGAlib is not too stable and using it is
inherently a little dangerous, you might want to have a way to log in from a
remote terminal if things go horribly wrong. If you are very unfortunate, you
might lock up your machine otherwise.
Note that you must be root to run SVGAlib programs. Making UAE suid root is
_not_ a particularly good idea if you care about the security of your system.
If you have a BeBox, you should not run configure. Instead, compile UAE by
doing "make bebox".

If you configure UAE for building the X11 version (which is the default if you
simply say "configure"), the configure script will try to find the program
"wish4.0" in the path. You can disable the UAE user-interface by passing the
"--disable-gui" option to configure. By default, the X11 version of UAE
tries to use a GUI written in Tcl. This requires Tk version 4.0. The SVGAlib
version uses a ncurses-based user interface.

The compilation may take a while, especially for the cpu*.c files. There might
be some warnings, ignore these. It may also take a lot of memory. You should
have at least 8MB physical RAM to compile this, plus maybe 10MB swap and 9MB
filesystem space.

After compilation, you'll need to install the ROM image. This must have a size
of exactly 512K (if you only have a 256K image of a 1.x Kickstart, that should
work, too) and should be an image of the addresses 0xF80000-0xFFFFFF on
your Amiga system. The file must be called kick.rom to be recognized. Please
read the next section on how to transfer files from your Amiga to your PC.

You also need to install a disk image file. This must be called df0.adf (adf =
Amiga Disk File), and should be a raw image of the data on the floppy disk:
11x2x80 sectors == 901120 bytes.
Please try running UAE without a diskfile first. If everything went O.K., the
emulator should show the Kickstart logo (don't be too impatient, this will
take a while on slow machines).

If you don't have a Kickstart file, you may still be able to boot some games
and demos. The emulator includes some primitive bootstrap code that will try
to read and execute the bootblock of the diskfile you are using, and if that
bootblock only uses the one or two Kickstart functions that are supported by
the "replacement Kickstart", your program will boot. Don't expect too much,
though.

If you are a daring person, you can edit custom.c before compiling and enable
the "EMULATE_AGA" define. UAE will then try to emulate some AGA features. I'd
like to hear feedback as to how well it works (expect it not to work at all
for a start).


Invoking UAE
============

After building the program, you should have an executable called "uae". You
can simply execute it, but you can also optionally give it one of the following
parameters:

General options:
 -h      : Give help on the options.
 -f n    : Sets the frame rate to 1/n. Only every nth screen will be drawn.
 -a      : Add no expansion devices. This will disable fastmem and harddisk
           emulation, but some extremely badly-written games may need this.
 -l lang : Set the keyboard language. Currently, the following values can be
       used for lang: "us" for U.S. keyboard (default), "se" for swedish,
       "fr" for french, "it" for italian  or "de" for german keyboard.
 -0 file : Try to use file as diskfile for drive 0 instead of df0.adf.
           -1 file, -2 file and -3 also exist for the other drives.
 -r file : Use file instead of kick.rom as Kickstart image.
 -J      : Use the numeric pad for joystick emulation (with 5 and 0 as fire
           buttons). This will turn off real joystick support. It's no good
       for action games, but may be useful for other games.
 -x      : General-purpose option. For the X version, it makes the X cursor
           visible (recommended). For the SVGAlib version, it turns off
       linear framebuffer support (sometimes, with -d 4, SVGAlib is
       faster without linear framebuffer).
 -o      : Allow UAE to overwrite ~/.uaerc with the selected options. This is
           only used by the text-based GUI in the SVGAlib and DOS versions.
 -G      : Disable the user interface (if present).

Emulating external devices (harddisk, printer, serial port):
 -M VOLUME:path
 -m VOLUME:path
           mount the unix file system at path as an Amiga filesystem with
       volume name "VOLUME:". For example, "-M sound:/usr/amiga/modules"
       If you use -M instead of -m, the volume will be read only.
       See below.
 -p cmd  : Enable printing. See below.
 -I dev  : Use "dev" as serial device (e.g. /dev/ttyS1 on Linux). Doesn't
           really work yet, at least not for me.

Sound options:
 -S n    : If your version of UAE supports sound, set the sound support level
           with this option.
       n = 0: No proper sound emulation at all. May be incompatible
              (unlikely). This is the default.
       n = 1: Emulate the sound hardware, but don't output sound. May be
              needed for compatibility, but can be much slower
       n = 2: Emulate the sound hardware and output sound. Recommended.
       n = 3: Emulate the sound hardware _exactly_. I don't think you'll
              hear a difference. SIDmon modules will be emulated
          correctly, but painfully slow with this setting.
 -b n    : Use n bits for sound output (8 or 16)
 -R n    : Use n Hz to output sound. Common values are 22050 Hz or 44100 Hz.
 -B n    : Use a sound buffer of n bytes (use small values on fast machines)
           Default is 8192.

Memory options:
 -s n    : Emulate n*256K slow memory at 0xC00000. Some demos/games need this.
 -F n    : Emulate n megabytes of fast memory as an expansion board.
 -c n    : Emulate n*512K chip memory. The default is 2MB chipram. Some very
           broken programs need "-c 1" to work properly.

Debugging options:
 -D      : Don't start the emulator at once, use the built-in debugger.
 -i      : Print illegal memory accesses
 -g      : Emulate parts of the OS. This isn't very stable and not
           recommended.

Display options:
 -d mode : Select a graphical resolution for UAE to run in.
 -H mode : Select a color mode to use.
 -C      : Correct the aspect. Normally, graphics will be only half as high
           as they should be, this option draws every line twice to correct
       this. It makes the emulation slower, though.
       Proper emulation of interlace mode is impossible without this
       option.

Resolutions: 0 (320x200); 1 (320x240); 2 (320x400); 3 (640x480);
             4 (800x600).
Color modes: 0 (256 colors, default); 1 (32768 colors); 2 (65536 colors)
             3 (256 colors, with dithering to improve color quality)
         4 (16 colors, dithered); 5 (16 million colors)

UAE may choose to ignore and/or refuse some combinations of these two
parameters. Some of these modes may also fail to work on your system.

You can also put these options into a configuration file in your home
directory. Simply create ~/.uaerc and put some of these options in it. On
non-Unix systems, the file is called uae.rc and should be located in the
current directory.

If you use SVGAlib, the only way to leave the program is pressing F12.


Choosing color and screen modes
===============================

As described in the previous paragraph, UAE can run in many different
resolutions and color modes. However, few of the color mode options are
available if you use the X11 version of UAE, since the X server determines
how many colors are available. If you are running a 256 color X server, you
can use "-H3" to tell UAE to dither the colors for better results.

You will have to experiment which mode gives the best results for you at a
satisfying speed. Note that the dithering process consumes time, so even if
256 colors with dithering look better than 256 colors without, remember that
UAE will be slower in that mode.

The low-resolution (320x???) modes should help some of the proud owners of new
P6 systems with a broken chipset and an exciting PCI performance of 4MB/s :-)

The recommended resolution is 800x600. In the lower resolution modes, some
overscan pictures the Amiga tries to display may not fit entirely on the
screen, others may be off-center and some graphical effects may look weird.
For best results, use 800x600 with at least 32768 colors.


Harddisk emulation
==================

!! Careful: All of this has been rewritten for this version. There may be
bugs, please report any strange events.

Using diskfiles is awkward. There are two ways how you can use larger amounts
of data with UAE. UAE can emulate more than one harddisk at one time, the
volumes will be named UAE0:, UAE1:, etc. UAE will boot from UAE0: if no
diskfile is found for floppy drive 0.

a) Harddisk files.
You can create a (unformatted) harddisk file with

  dd if=/dev/zero of=hardfile bs=512 count=16384

Currently, the size is fixed (8MB).

The harddisk file is accessed by a resident ROM module that is built into the
emulator, called "hardfile.device". If it is present, this is always the first
harddisk device the emulator finds and will be named UAE0:

If you are using Kickstart 1.3 or earlier, this can't currently be mounted at
boot time, and therefore you can't boot from it either. You will have to boot
either from a floppy disk image or from a filesystem (see below), and mount
the hardfile.device later. To do this, add the following to "DEVS:mountlist":

UAE0:       Device = hardfile.device
       Unit   = 0
       Flags  = 0
       Surfaces  = 1
       BlocksPerTrack = 32
       Reserved = 1
       Interleave = 0
       LowCyl = 0  ;  HighCyl = 511
       Buffers = 5
       DosType = 0x444F5300
       BufMemType = 1
#

Then, type "mount UAE0:" (or put that command in your startup-sequence), and
you should be able to access it. Don't forget to format it with the AmigaDOS
format command:

  format drive uae0: name Mister_Willwink

b) Access native filesystems from the emulator.

This has some major advantages:
 - It has no problems with Kickstart 1.3
 - It is more convenient.
 - It is much faster. In fact, it can be dramatically faster even than a real
   Amiga when reading directories.

However, it currently does not work on some ports.

If you specify the -M or -m command line arguments, you can use files on your
Unix filesystem from the emulator. If you start UAE with

  uae -m sound:/usr/amiga/modules

you can access all the files in /usr/amiga/modules by reading from the
AmigaDOS volume "SOUND:".
(DOS users: try "uae -m dh0:C:\" to mount your drive C:\ as DH0:)

If you want to execute files, they need to have the x permission bit set.
That can be done in Unix by "chmod +x file" or in AmigaDOS with
"protect file rwed".
You can mount up to 20 devices by giving this option multiple times.


Tools / Transferring files
==========================

To transfer any software between an Amiga and another computer, you'll need
either a tool like CrossDOS or MessyFS on the Amiga that lets you read and
write PC formatted disks, or a serial null-modem cable. CrossDOS is part of
the newer Amiga operating systems; MessyFS is free software and can probably
be found on some old Fish disk. To transfer data over a null-modem cable it is
useful to use some sort of terminal software on both ends. I can't explain
here in every detail how to use terminal programs or CrossDOS. Please read the
appropriate documentation. Note: If you use a tool to read/write PC-formatted
disks on the Amiga, remember that most Amiga drives handle only DD disks, so
don't try to use HD floppies.

In the "amiga" subdirectory you'll find two small Amiga programs that you can
use to transfer software from the Amiga to the PC. These are called transrom
and transdisk. Copy them to your Amiga and make them executable (by typing
"protect transrom rwed" and "protect transdisk rwed" in the Amiga shell
window).
transrom will dump the contents of your Kickstart ROM, and transdisk will
dump an image of a floppy in one of the drives. Both programs write to the
standard output, so you'll want to redirect that. Do

   transrom >ram:kick.rom

to create a file called "kick.rom" in the RAM disk, and

   transdisk >ram:df0.adf

to create a file called "df0.adf" in the RAM disk. These files are pretty
big, 524288 bytes for the ROM image and 901120 bytes for a disk image.
transdisk understands the following arguments:

    -d device unit: Use this device instead of DF0:
    -s n: Begin transfer at track n (default: 0)
    -e n: End transfer at track n (default: 79)

So, to transfer the disk in drive DF1:, you'd give the command:

  transdisk >ram:df1.adf -d trackdisk 1

If you don't have much RAM and can't fit all of a disk image in the RAM disk,
you can split up the transfer into multiple parts with the "-s" and "-e"
parameters. To transfer the disk in four parts, you'd use the following
commands:

  transdisk >ram:df0_1.adf -s 0 -e 19
  transdisk >ram:df0_2.adf -s 20 -e 39
  transdisk >ram:df0_3.adf -s 40 -e 59
  transdisk >ram:df0_4.adf -s 60 -e 79

Of course, you should save each of the four files to another place before
transferring the next one with transdisk to make space in your RAM disk.
If you have all the files on your PC, you can do the following under Unix:
  cat df0_1.adf df0_2.adf df0_3.adf df0_4.adf >df0.adf
or, under DOS:
  COPY /B df0_1.adf df0_2.adf df0_3.adf df0_4.adf df0.adf
I've been told there are the following tools for the Mac to join binaries:
"ChunkJoiner 2.1.2" found under Info-Mac's <disk> directory or
"JoinFiles 1.0.1" under Info-Mac's <text>.

The current transdisk can only read the standard AmigaDOS format. This means
that most games that rely on some form of copy-protection cannot be
transferred. However, there are disks that are formatted in the normal 880K
format that transdisk can read, but don't have a filesystem ("NDOS" disks
in the Workbench). These will be transferred correctly.

There's an easy way to use a null-modem cable without terminal software if
you use Linux. You can do

  transdisk >SER: <options>

on the Amiga to copy the data directly to the serial port. Before that, do

  cat /dev/ttyS1 >df0.adf

on your Linux box to receive the data (it may be ttyS0 on your system, or
another number, depending on which serial port you are using). When the Amiga
is done transferring, hit ^C on the PC to interrupt the cat program. To make
this work, you need to use the same settings for the serial port on both
sides. This is done with the Preferences program on the Amiga (this is split
into several programs from Kickstart 2.0 upwards, you'll find a program called
"serial" in the Prefs directory of your Workbench disk). On the Linux side,
use the stty program. "man stty" will give you the manpage describing how to
use it.
To be on the safe side, set the speed to a low value (2400 baud). Turn off
Xon/Xoff, but enable RTS/CTS.
I use the following command myself:

  stty 19200 parenb -cstopb cread clocal crtscts -istrip -inlcr -icrnl -opost
    -onlcr -parodd -isig -icanon -iexten raw cs8 </dev/ttyS1

which is probably overkill, but you never know :)
This maps to 19200 baud, 8 bits, even parity, one stop bit, which you have to
set in the Amiga preferences.

If you transfer commercial software, you must not distribute the resulting
image files, since that would be a violation of copyright law. The Kickstart
ROM has to be considered commercial software. You may only use the Kickstart
from your own Amiga, and you may not distribute Kickstart ROM files.
Please read the license that came with your software for details.

If you have a disk image file, and you want to retrieve the files from it, you
can use the "readdisk" tool. It is automatically built by "make". If you have
a disk image of a disk called "Workbench1.3D" as df0.adf, and you do
   readdisk df0.adf
the whole directory structure of the disk image will be stored in a newly
created subdirectory called "Workbench1.3D". You can optionally give a second
parameter to specify a directory where to create the output other than the
current directory.
readdisk only understands about the OFS right now. FFS disks will cheerfully
be regarded as being unreadable. Use the unixfs.device from within the
emulator if you want to transfer files from FFS disks. If you use Linux with
a kernel version >= 2.0.7 and version 2.5k of the mount program, you can do
   mount df0.adf /mnt -t affs -o loop
You'll need to enable support for the Amiga filesystem and the loop device
when configuring and compiling the kernel.



The UAE_CONTROL program
=======================

In the "amiga" subdirectory, you will find two programs, uae_control and
uaectrl that provide the same functionality as the X11 GUI. uaectrl is
shell-based and works with any Kickstart, while uae_control needs the
gadtools.library and a recent version of reqtools.library, so it only works
with Kick 2.0 and upwards. Copy these two programs to the directory that you
use for harddisk emulation. They should be self-explanatory.


Printing
========

With the "-p cmd" option, you can specify a command that will be run when the
emulator detects that the Amiga accesses the parallel port. Usually, you will
want to say "-p lpr" to pass the output over to lpd. It's unclear how this
will work on non-Unix systems, DOS users can try "-p LPT1:" or something like
this.
For best results, select the PostScript driver in the Amiga Preferences. This
is only available in newer Kickstarts. Printing is not going to work with
another printer driver.
None of this is guaranteed to work yet, and I have not tried any of this yet.


Quick overview of the debugger commands
=======================================

If you use the X11 version, you can press ^C at any time to enter the built-in
MC68000 debugger.
Each debugger command consists of a single letter and occasionally some
parameters.

g:                    Start execution at the current address.
c:                    Dump state of the CIA and custom chips.
r:                    Dump state of the CPU
m <address> <lines>:  Memory dump starting at <address>
d <address> <lines>:  Disassembly starting at <address>
t:                    Step one instruction
z:                    Step through one instruction - useful for JSR, DBRA etc.
f <address>:          Step forward until PC == <address>
q:                    Quit the emulator. You don't want to use this command.

(^C has no effect if UAE is compiled for SVGAlib - use F12 to exit)


Input devices
=============

Mouse, keyboard and joystick can be used in a straightforward way. A couple of
keyboard languages are supported with the "-l" commandline option. If you have
a different keyboard, patches to make UAE work with it are appreciated.
The X version of the emulator will try to keep the Amiga mouse pointer at the
same location as the X mouse pointer. You can turn off this mode if it does
not work with your program by pressing F12. This is needed (for example) for
Lemmings and the Magnetic Scrolls adventures, which don't use sprite 0 as a
mouse pointer. Other versions (SVGAlib, DOS, possibly others) do not have this
problem.
If you use Linux and have the joystick driver kernel module, "configure"
should automatically enable support for it. UAE calibrates the joystick
automatically. Turn it a few times on startup to get the calibration done.


Sound
=====

If you define LINUX_SOUND in config.h, the emulator will use /dev/dsp to
output sound. You can pass parameters like frequency or number of bits to use
on the commandline; if you don't specify any, sane defaults will be used. If
graphics output is enabled while sound is output, the emulator will be much
too slow on most systems. The sound will not be continuous. Therefore, a hack
to turn off screen updates is provided: Press ScrollLock to disable graphics,
press it again to enable them (note: for X, you'll have to press it twice each
time).
The LINUX_SOUND_SLOW_MACHINE option will steal cycles from the CPU emulator.
The relative CPU speed will be reduced somewhat if this option is set. This may
lead to incompatibilities.

The quality of the emulation depends on the setting of the "-S" commandline
option. With "-S 3", all of the sound hardware is emulated; and some programs
(e.g. AIBB) won't run with other settings. "-S 2" should sound just as good as
"-S 3" and will be much faster for some programs. "-S 1" tries to emulate most
of the sound hardware, but doesn't actually output sound. "-S 0" completely
turns off sound.

On other Unix systems, the AF sound system may be available. You can configure
UAE to use this, too, by changing some paths in the Makefile (I can't answer
any questions about this, I never saw/used it).


Speed
=====

The Most Frequently Asked Question is: "Just how fast is it?", and this is
also the most difficult one to answer. The easy way to answer is "It depends",
but I'll try to do better. All timings I give here were measured on my
machine, a P90 (using SVGAlib, with all the x86 assembly options turned on).
The MC68000 emulation is more than twice as fast as a real A500. I measured
this by letting PowerPacker try to compress itself (it already was compressed).
It took UAE about 6 minutes, my A500 took about 15. If you set the frame rate
to a high value (i.e. leaving out many frames), the graphics speed does not
matter and you get about twice the speed of an A500. If you enable the smart
update method in config.h, and if it works for your program (it works for
almost all programs using the Workbench) you also get about the same speed at
full frame rate.
For games and demos, the CPU speed does not matter, but the average frame time
is important. UAE can calculate this automatically. The SVGAlib version gives
the number when you exit the emulator, to obtain the value with the X version
you need to interrupt it and type "c" in the debugger. A real A500 has a
constant frame time of 20ms (50 Hz).
If you have a game/demo that has lots of blitter activity, many copper/sprite
effects, dual playfields and scrolling, no one can help you. Fortunately, this
case is extremely rare. Normal games that have a number of blitter objects,
scrolling and maybe some sprites run at 1/3-1/4 the speed of an A500 in the
worst case, some run at 1/2 the speed. Lowering the frame rate helps
enormously here, and at 1/5 frame rate, about everything runs somewhere
between 50% and 100% the speed of an A500.
This still isn't the full story (I bet you start to see why the question is
hard to answer). A real A500 without fast memory gets slowed down to about
half its speed in Hires 16 color mode. More bitplanes also slow UAE down, but
not quite as much, so it can be several times faster than an A500 in that
mode.


Bugs / Unimplemented features
=============================

The sprite emulation is incomplete and buggy. Sprite collisions are not
implemented yet. The serial port emulation doesn't seem to be useful yet.
Apart from that, UAE can do everything a real A500 can do (and more), but
there may still be one or two buglets that make some programs fail.


Thanks & Acknowledgements
=========================

Thanks to all who have written me so far with bugreports and success/failure
reports when trying to run the emulator on various hardware with different
Kickstart versions. A list of everyone who has contributed to the source code
can be found in the CREDITS file (this was getting too big to keep it here).

Special thanks to:
  - Jay Miner, Dale Luck, R.J. Mical and all the others who built the Amiga.
  - Felix Bardos, whose HRM I "borrowed".
  - Hetz Ben Hamo mailed Peter Kittel from Commodore asking for permission to
    give Kick 1.3 away. Unfortunately, the response was negative :-(
  - Bruno Coste, Ed Hanway, Alessandro Soldo and Marko Nippula provided
    documentation
  - Fabio Ciucci gets the "Best bug reports" award for his help with the
    blitter line emulation and other problem areas.


Ports
=====

Apart from the "main" Unix version, several ports of UAE are ready/being
developed.

Gustavo Goedert <[e-mail]> has ported UAE to DOS using the
DJGPP port of GCC. The binary is available on several ftp sites as well as on
my Web site.

Ernesto Corvi <[e-mail]> has ported UAE to the Apple
Macintosh. He tells me it is available on Info-Mac, and that every Mac user
should know where that is. A link to the archive containing both PPC and 68k
binaries is on my Web page. (info-mac is mirrored by
sunsite.informatik.rwth-aachen.de)

Christian Bauer <[e-mail]> has ported UAE to the
BeBox.

Ian Stephenson <[e-mail]> has ported UAE to NextStep.

Olaf 'Olsen' Barthel <[e-mail]> has ported UAE to the Amiga. This
port requires the AA chipset as well as Kickstart 3.0 or higher. CyberGraphX
is supported. Please read the file "amiga.c" for information. To compile it,
you need SAS/C and the 3.0 includes (they probably come with the compiler).

Krister Bergman <[e-mail]> has ported UAE to the XFree86/OS2
environment. This port can be obtained from Krister's WWW page:
<http://www.kuai.se/~bellman/html/xfreeapps.html>

Since I generally don't have the possibility to test or improve these ports,
it is a good idea to contact their respective authors if you have questions.


Pointers
========

There are a few sites in the Internet that contain helpful information about
UAE.

I have set up a WEB page for UAE. You will find interim versions, Linux
binaries, diskfiles with Amiga software and other interesting stuff there.
The address is

http://www-users.informatik.rwth-aachen.de/~crux/uae.html

There, you will find links to other UAE pages. I'll add these links to this
document in the next version, but I don't have them here right now.

I post announcements of new versions of UAE to the newsgroup
comp.emulators.misc. From time to time, I also upload new versions to the ftp
server sunsite.unc.edu. You will find them either in pub/Linux/Incoming or in
pub/Linux/system/Emulators. There are many sunsite mirrors throughout the
world, you should be able to find one near you.


The author's address
====================

Before you contact me with a problem that you have, make sure you have read
_all_ of the above. Please read also the file "FAQ", which conains a lot of
helpful information. In the future, I will probably no longer respond to
questions that are already answered by any of these files.

[e-mail]

or, via snailmail

Bernd Schmidt
Schlossweiherstrasse 14
52072 Aachen
Germany

Email is more likely to be answered, and will definitely be answered much
faster. Please avoid phonecalls if you can.
I can't answer _every_ question. If you have trouble understanding this
README, either because you don't speak English very well or because you have
no clue at all about computers, please try to find someone near you who does
understand this file and who can translate/explain it for you. I simply can't
explain (for example) how to use terminal programs or CrossDOS because I don't
use either, and it would be much too time-consuming anyway. This file and the
file FAQ contains about every piece of information I can give you. I try to
help people who have questions, but sometimes it takes too much time.

Please don't ask for Kickstart ROM files.

Oh, and another thing: If I promise to do things (like implement new
features), and forget about them, pester me. That happens occasionally, it's
a known bug in my brain. I'll have it replaced.